Date: Fri, 29 Oct 93 04:30:02 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V93 #280 To: tcp-group-digest TCP-Group Digest Fri, 29 Oct 93 Volume 93 : Issue 280 Today's Topics: AMPR and gatewaying (3 msgs) Re- TCP broadcast storm unsubscribe Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: 29 Oct 93 00:19:57 EDT From: Bob Ross <72277.550@CompuServe.COM> Subject: To: tcp-group unsubscribe ------------------------------ Date: Thu, 28 Oct 93 16:53:06 EDT From: crompton@NADC.NADC.NAVY.MIL (D. Crompton) Subject: AMPR and gatewaying To: gateways@mpg.phys.hawaii.edu, tcp-group@ucsd.edu I see a possible trend in gateways that is bothering me somewhat. That is using a "wired/commercial" network to pass AMPR traffic WHEN an existing AMPR circuit either exists or could easily be made to exist. Certainly there is no argument for many of the circuits - I.E. Australia to the US etc. The problem is when you have two adjacent areas within the US that use gatewaying when an AMPR radio cicuit exists. We are Amateur Radio and RF is our "thing". Modulating it with digital data or whatever. The more we depend on "wired" networks the less autonomous we become. I see this reasoning starting to set in here on the East coast. "Well it's a whole lot less trouble to just gateway than setup an RF link, so why bother. We have RF links that are a mess. Have we lost sight of what this is all about? I really think there should be a policy established on this. Amateur (RF) circuits should be used whenever possible. If they do not work well or we need to improve the RF protocol then lets go ahead and do it. Anyone can send data down a wireline especially when the transport is being handled by someone else. The last time I checked we were Amateur RADIO operators, not Amateur network operators. I guess if every user had FREE internet connections at their home they would be happy - hey then you would not need the radio! Seems to be what everyone is pushing for anyway. I am contemplating setting up a gateway. It will be my policy if and when I do, to NOT pass traffic to areas which can be reached by RF. I don't care how slow the circuit is. If engineering wise a circuit is feasible via RF than that's the way it should go. Perhaps some will think that is to strong an approach, but I think that we really have to take a good look at this and try to see where it is all going. I work with "wirelines" all day long and it is no big thrill in my book to have data go half way around the world in that manner, much the same as we take making a worldwide phone call for granted. Send the same via radio though and it will excite the real "RF freaks". Maybe technology has really gone beyond Amateur radio. It won't be to many more years when you will have a palm size personal communicator that will transceive in many modes to anywhere in the world via satelite. Of course it will cost money, a dirty word for most hams. Oh I guess that is why all this gatewaying has caught on - it is FREE. If it cost money we would not be doing it. Which brings up a point - someone IS paying for it. We are just on a free ride. Fire away... Doug ------------------------------ Date: Thu, 28 Oct 93 12:38:40 HST From: Antonio Querubin Subject: AMPR and gatewaying To: crompton@NADC.NADC.NAVY.MIL (D. Crompton) > I see a possible trend in gateways that is bothering me somewhat. > That is using a "wired/commercial" network to pass AMPR traffic > WHEN an existing AMPR circuit either exists or could easily be made > to exist. The situation is similar to the distribution of satellite gateways around the world. Some places have too many, some not enough. > I really think there should be a policy established on this. Amateur (RF) > circuits should be used whenever possible. If they do not work well or > we need to improve the RF protocol then lets go ahead and do it. Anyone Not sure if we need a set policy. I'd rather let common sense take over and have people in the same region cooperate to make maximum use of the resources they have. I've gotten a lot of initial contacts from people thinking about setting up a gateway where there is one already nearby. I inform these people about the nearby gateway and it's their choice as whether to pursue a new gateway, or help out with the existing network surrounding the nearby gateway, or simply become end-nodes. > can send data down a wireline especially when the transport is being handled > by someone else. The last time I checked we were Amateur RADIO operators, > not Amateur network operators. I guess if every user had FREE internet We are amateur communication operators. The media and modes of communication that we use will continue to increase and evolve. Consider communication via fiber optics for example. This is still communication via E&M waves. The fiber is nothing more than a dielectric waveguide. The wavelength is measured in nanometers. This is by no means a stagnant hobby. > connections at their home they would be happy - hey then you would not > need the radio! Seems to be what everyone is pushing for anyway. True. The way things are going the average Joe may get Internet access by landline before the ham next door does by radio. > I am contemplating setting up a gateway. It will be my policy if and > when I do, to NOT pass traffic to areas which can be reached by RF. I > don't care how slow the circuit is. If engineering wise a circuit is > feasible via RF than that's the way it should go. Well, Hawai`i IS reachable via 300 BAUD HF packet from the U.S. mainland and Australia. But I don't expect us to go back to that. I'd rather wait for geostationary satellite routing. > via satelite. Of course it will cost money, a dirty word for most hams. > Oh I guess that is why all this gatewaying has caught on - it is FREE. If > it cost money we would not be doing it. Which brings up a point - someone > IS paying for it. We are just on a free ride. May as well enjoy the ride while it lasts :-). Tony ------------------------------ Date: Thu, 28 Oct 1993 23:38:00 -0600 (MDT) From: William Ti Baggett Subject: AMPR and gatewaying To: "Dr. Osborne AA5ZQ" On Thu, 28 Oct 1993, Antonio Querubin wrote: > > I see a possible trend in gateways that is bothering me somewhat. > > That is using a "wired/commercial" network to pass AMPR traffic > > WHEN an existing AMPR circuit either exists or could easily be made > > to exist. I have thought about and discussed with others this topic for some time now, but not really to any great extent. I agree that RF links should be used whenever they exist, but from my (limited) experience in packet radio so far, making RF links exists is not as easy as I thought. So here's my 2 cents worth. > > We are amateur communication operators. The media and modes of > communication that we use will continue to increase and evolve. > Consider communication via fiber optics for example. This is still > communication via E&M waves. The fiber is nothing more than a > dielectric waveguide. The wavelength is measured in nanometers. > This is by no means a stagnant hobby. This is where I start having an opinion. I agree with Tony here. There is a lot more to communication than just antennas and transmitters, at least from what I've gotten out of Ham Radio in the past 8 years. When we get to the basics, its all E&M waves, but thats not the point I'm trying to make. I'm an undergraduate Electrical Engineering student here at New Mexico State University. I've found that amateur radio is a fascinating hobby with a lot of different fields that one can enjoy and learn about. This has inspired me to choose my major that I have. I also happen to enjoy the digital communications end of amateur radio and because of this I have set up the gateway on campus here (NMSUGW). From this experience I have learned (and continue to learn) an INCREDIBLE amount about computer networking with protocols and the different problems that arise from it. I am by no means a digital communications guru like several are who read these groups, but it is still applicable knowledge. TCP/IP (at least to me) works the same over Ethernet and the radio - only their physical data layers are different. Currently, I'm even running several experiments to determine packet retry rates for different protocols, and in the future may experiement around with different modulation schemes. THAT is what I think amateur radio is. It's not just radio anymore. It is non-professionals (which I am) experiementing and developing new methods of communications. Interfacing radio packets into different LANs Via Internet is something that the gateway sysop's are developing and experimenting with. > > > connections at their home they would be happy - hey then you would not > > need the radio! Seems to be what everyone is pushing for anyway. > > True. The way things are going the average Joe may get Internet > access by landline before the ham next door does by radio. > Yeah, especially at 1200 bps which most probably 98% of hams are using (at least around here). Also compare prices: 2nd phone line: $30 installation / $16 a month 14.4Kbps V42bis modem: $147 Heck I cant even get Digital Music Express from our cable company for that. So, do you want Internet access or communication with other amateurs? I prefer chatting with amateurs rather than the other students, etc on IRC. But thats me. If you want Internet access, but a telephone modem and get on the Internet somehow. If you want on packet, get a TNC and a good radio modem. The gateway here is intentionally set up NOT to allow amateurs access to the Internet. We saw no reason why we should. We are only providing a method to route amateur packets from southern NM to other parts of the world. This depends on the gateway administrators. This is also where the feasiblity of RF links come in: OPINION ALERT! This digital communications stuff is TOO complicated for the average packeteer! I do not think that amateur radio as a whole is any longer on the leading edge of technology. The communications graduate students here at NMSU have some real INTERESTING digital communications projects. After seeing them present their papers about interleaving, 8 PSK, 16 PSK, etc I wonder why we're still at FSK. Maybe bandwidth has something to do with it. I'll learn more as a graduate student myself. However, I don't think hams are going to want to build their own RF radios to handle weird modulation schemes. Yeah, the FCC may restrict the modulation schemes, but we can get approval for experimentation. At 9600 bps, 19.2Kbps, or even 56Kbps (which is getting pretty technical) I don't think amateur radio will ever have a fully interconnected network. I hope that I'm wrong and I intend to tinker with my own modems someday when college is not such a factor. I think the hams should design their own stuff instead of having someone else do it for them. Only difference with buying ready made equipment for a 9600 bps network and the Internet is that the Internet is already in place. I could continue by commenting about how hard it is to find protocol specs for someone who wants to develope something, but I think I beat that horse a few weeks ago. > > I am contemplating setting up a gateway. It will be my policy if and > > when I do, to NOT pass traffic to areas which can be reached by RF. I > > don't care how slow the circuit is. If engineering wise a circuit is > > feasible via RF than that's the way it should go. Again, I do not think amateur radio operators are going to go to the trouble of 'engineering' a network (at least most of them). Money, and equipment seem to be factors in developeing a fully conencted network. I agree with using common sense when it comes to routing from the gateways. El Paso has NEVER had a packet connection with the rest of Texas. It now has one. However, Each town does not need a gateway. The gateways and the Internet can act as a 'super highway' backbone while 9600+ backbones can be implemented to get traffic from several LANS into the gateway. > > Oh I guess that is why all this gatewaying has caught on - it is FREE. If > > it cost money we would not be doing it. Which brings up a point - someone > > IS paying for it. We are just on a free ride. Well, my tuition and taxes are providing the connection to Internet for our radio club. If it disappeared tomarrow, I think I got a good education out of setting up a gateway (I can even talk intelligently with the networking folks on campus! Hmmm, wanna hire someone?) BTW: NMSU networking was really interested in our project and how amateurs run TCP/IP over RF. Unfortunatly they weren't impressed at the 500+ second Round Trip Time to Albuquerque... > > Flame On... I dont consider my comments as flames (and I hope no one else does either). These are just my personal opinions. Heck, I'm still young and new to this. These are just my observances. I hear some people already saying it: 'He wants to build something??!! I bet he also likes CW!' Yep, I enjoy CW. Just wish school didnt take so much time that my code speed has fallen from 20 wpm to 2 wpm ;-) I'll step off my disillusioned soapbox now and do some homework... 73, AA5DF, Tim Disclaimer: As an undergraduate student I'm not allowed to hold an opinion that in any way, shape, or form reflects that of NMSU. ******************************************************************** Tim Baggett, AA5DF Electrical Engineering Student New Mexico State University Internet: WBAGGETT@DANTE.NMSU.EDU AMPR: AA5DF@NMSUGW.AMPR.ORG US Snail: 1970 Buchanan Avenue Twisted Pair: (505) 523-6828 Las Cruces, NM 88001 ******************************************************************** ------------------------------ Date: 27 Oct 1993 17:45:00 U From: "MGauthier" Subject: Re- TCP broadcast storm To: TCP-Group@ucsd.edu Subject: Re: TCP broadcast storm [To R. Braden: there is a question (or observation) at the end of this message asking why RFC 1122 doesn't explicitly say that TCP should always ignore and never generate broadcast/multicast packets, instead of just mentioning SYN packets.] |From: "Ray Abbitt" |SUBJECT: Kind of interesting problem. | |>From: Glenn Davis |>Subject: TCP broadcast storm |>I am troubleshooting a particularly devilish network problem. About two |>days ago I started seeing very high TCP broadcast traffic on our internal |>TCP/IP network. After taking a network sniffer to the problem I discovered |>packets like: |> |>13-OCT-1993 02:59:09.76 02-60-8C-A5-4F-BD FF-FF-FF-FF-FF-FF 08-00 len= 46 |>IP: vers=4 hdrlen= 5 lngwrds, svc:Routine |> total len= 40 ID=%X967E frag ofs= 0 |> TTL= 30 prot= 6 TCP (Transmission Control), cksum=%X3B1E |> src=255.255.255.255 dest=255.255.255.255 |>TCP:port:src=31876 dest=132 seq#=523398 ack#=523398 |> window=0 len=5 Lwrds,ACK,RST cksum=39AD urgentptr=0 |>FFFFFFFF 3B1E061E 0000967E 28000045 E..(~......;.... 0000 |>86FC0700 86FC0700 8400847C FFFFFFFF ....|.....|...|. 0010 |> 4646 45434620 0000AD39 00001450 P...9Z.. FCEFF 0020 |> |>Approximately 35 network stations (PC's running Netmanage TCP/IP) were |>sending out these packets as fast as their network adapters would allow! |> |>What seemed to happen is: each station would see a packet like the one |>above, and send out a RST (reset) response (ie this packet not for me). |>This would repeat itself ad-nauseum, dragging the network down with all |>the broadcast traffic! |>[...] |>The only thing that stopped the beast was to shut down the entire network! | |I ran this by one of the other guys at work and got this reply: | |FROM: FRANK H. COLETTI(FRCO@CHEVRON.COM) |Subject: Kind of interesting problem. |Ray: This is a known bug in TCP traffic and was probably started by some- |one who intentionally wanted this to happen. As far as I understand it |you can start it by custom making an ARP packet, or some other such packet, |and instead of putting your MAC address in the source field, you put the |broadcast address. This causes other machines that get the packet via the |broadcast to respond and automatically put in the original packet's |source address-in this case, the broadcast address again. This causes |a "Broadcast Storm" and what you saw is exactly what happens. It brings |the network to its knees. In one of the classes I attended they said |that some college guy did it on the Internet a couple of years ago and |promptly brought the Internet down. |[...] I don't think this is a "known bug in TCP traffic", but rather a bug in that particular TCP implementation (unless you mean that particular bug is known to be present in a number of TCP implementations). A TCP should NEVER reply to a RST packet. Although it's a bit spread out, this is rather clear from RFC 793 ("SEGMENT ARRIVES", pages 65-76), and from this explicit paragraph on page 36: 1. If the connection does not exist (CLOSED) then a reset is sent in response to any incoming segment except another reset. In ^^^^^^^^^^^^^^^^^^^^ particular, SYNs addressed to a non-existent connection are rejected by this means. Generally speaking, a proper TCP/IP implementation should NOT be prone to broadcast storms. There are many discussions in the RFCs on steps that must be taken to avoid such possibilities. If you find software that generates broadcast storms, then most likely the software itself is the culprit. I know of no way for IP or TCP to be subject to broadcast storms, **when properly implemented according the the latest RFCs**. (Please correct me if you know full details of a valid counterexample.) I don't claim that most implementations are fully conformant :-) The above TCP/IP implementation has a second bug, the removal of which would avoid this broadcast storm. Simply said, IP packets with broadcast or multicast source addresses MUST be discarded. RFC 1122 says (for TCP and UDP): 4.2.3.10 Remote Address Validation A TCP implementation MUST reject as an error a local OPEN call for an invalid remote IP address (e.g., a broadcast or multicast address). An incoming SYN with an invalid source address must be ignored either by TCP or by the IP layer (see Section 3.2.1.3). A TCP implementation MUST silently discard an incoming SYN segment that is addressed to a broadcast or multicast address. 4.1.3.6 Invalid Addresses A UDP datagram received with an invalid IP source address (e.g., a broadcast or multicast address) must be discarded by UDP or by the IP layer (see Section 3.2.1.3). When a host sends a UDP datagram, the source address MUST be (one of) the IP address(es) of the host. It is clear from the above that broadcast and multicast addresses are not allowed as source addresses in IP datagrams, and that such datagrams should be discarded. This is also stated explicitly in section 3.2.1.3 of RFC 1122, on IP addressing: 3.2.1.3 Addressing: RFC-791 Section 3.2 [...] When a host sends any datagram, the IP source address MUST be one of its own IP addresses (but not a broadcast or multicast address). [I believe there is an exception to the above for IP-level IP address discovery protocols such as BOOTP, in which case 0.0.0.0 is used as a source address by the BOOTP client. -MEG] A host MUST silently discard an incoming datagram that is not destined for the host. ... [...] A host MUST silently discard an incoming datagram containing an IP source address that is invalid by the rules of this section. This validation could be done in either the IP layer or by each protocol in the transport layer. [...] I propose that the stated TCP/IP implementation has yet a third bug, removal of which would also prevent a broadcast storm. It is simply that TCP should never respond to broadcast or multicast packets. TCP is not a broadcast/multicast protocol, and should never generate (or respond to) such traffic. (I'm ignoring the ARP mechanisms, which operate at the network level; ARP has / should have its own mechanisms to avoid broadcast storms.) However, I couldn't find any explicit statement of this more general that what is found in section 4.2.3.10 of RFC 1122 (see above quote). Why isn't this clearly pointed out in RFCs? Looks like an omission... So the solution to Glenn's problem (other than shutting down the net for a short term fix) would be to contact the suppliers/writers of the TCP/IP software and tell them how buggy their software is. You could quote the above. 73, -Marc VE2SOR -- Marc E. Gauthier Software Eng. Lab, IIT, National Research Council Canada mgauthier@iit.nrc.ca Building M-50, Ottawa ON, Canada K1A 0R6 +1 613 991 6975 fax: +1 613 952 7151 home: +1 819 777 5841 (Hull QC) NCFreeNet: aj313@freenet.carleton.ca Disclaim: I speak for myself only ------------------------------ Date: Fri, 29 Oct 93 1:10:41 CDT From: umlee174@CC.UManitoba.CA Subject: unsubscribe To: tcp-group@ucsd.edu unsubscribe ------------------------------ Date: Thu, 28 Oct 93 15:35:40 +0100 From: Alan Cox To: tcp-group@ucsd.edu Several tcp/ip stacks respond with ACK's to out of sequence RST frames and break all the rules. Nevertheless with the exception fo the current Linux one (which I'm fixing) I know of none stupid enough to reply to a frame with broadcast addresses. ALan ------------------------------ End of TCP-Group Digest V93 #280 ****************************** ******************************